Note: Manual conversion from LaTeX did not preserve the citations. Imbedded pictures are represented as links to postscript files, which unfortunately are too big to store online (2.87 MB). You can download this report compressed (42 KB) including the postscript pictures here.

Exploring CSCW support for Software Development through Multiple Levels of Collaboration

Gene Thomas Department of Computer Science University of Canterbury Christchurch, New Zealand [email protected]

Abstract

Increasingly software development is carried out in teams, often leading to the concurrent modification of diverse aspects of the system under development. To work productively software engineers must be able to alternate between independent and collaborative work conditions while maintaining an awareness of others' activities. Introducing multiple levels of collaboration within a Computer Supported Co-operative Work (CSCW) system is an effective solution but increases user requirements in terms of workspace and temporal awareness.

Keywords

CSCW, groupware, version control, collaborative editing, software engineering.

1. Introduction

Effective collaborative software development has greater requirements than both single user software development and simple collaborative writing. Within this application domain their are two tiers of collaboration. At times the programmers need to collaborate closely with parties focusing on the same piece of code. At other times collaborators will wish to independently modify diverse aspects of the system, this later case has very different needs from the first. The modification and testing of separate pieces of code within one system cannot be carried out simultaneously, put simply, programmer A does not want to have to worry about programmer B's modifications to the system when trying to test and debug his/her own changes.

Tools are needed that forfill the needs of both levels of collaboration. Maintaining workspace awareness, the users' understanding of each others activities, while important in all groupware applications, [1], is critical within this application area given the added complexity of multiple levels of collaboration. One must be acutely aware of close collaborators actions while maintaining some understanding of participants working independently elsewhere in the system. Additionally, due to the large amount of data to be traversed, supporting temporal awareness, understanding the changes that have occurred in relation to time, is also of critical importance. Programmers must be able to shift their attention to diverse sections of the system without losing track of modifications made by others.

In this paper I review the potential of existing tools to support the task outlined above. I develop some design principals for the development of a suitable tools and discuss Medusa, a prototype collaborative version control and software editing system designed to fill these needs.

2. Background

Separate tools exist to support collaborative writing and parallel development of software systems. This section evaluates the potential of these systems to forfill the needs of collaborative software development. To facilitate computer supported group text editing research has been conducted in the area of collaborative writing.

Later generations of version control systems have been developed to support the concurrent modification of multiple versions of source code. I discuss their applicability to this task domain. Finally I evaluate the potential of combing these techniques to provide a feasible solution.

2.1. Collaborative writing

Collaborative writing is an area of research concerned with technologies to support distributed multi-person text editing. Much research and a number of systems have been produced [2]. A number of useful groupware ``widgets'' [1] have been developed to provide workspace awareness. These include:

Coloured text Text is coloured to indicate the author.
Group scrollbars A collaborative analogy of conventional GUI scroll bars, these show the current view positions of all participants.
Telepointers These show collaborators' mouse pointer locations.
Gestalt view This widget displays a miniature overview of the entire text being viewed with coloured boxes to indicate all participants view area.

These tools while supporting independent user focus between group participants are not suited to concurrent independent group software development as only one version of the text is maintained at a given time. However the developments in supporting workspace awareness are directly applicable to the closely-collaborative scenario multi person software development

2.2. Version Control

Version control systems allow the developer to maintain multiple versions of source code files and to track modifications. To edit files programmers ``check'' the data out of the system, perform their modifications, and return control of the file back to version control system. New versions can be created and documented as needed.

The original version control systems (RCS, Revision Control System [3] and SCCS, Source Code Control System, [4]) do not support multiple users working concurrently on different versions. CVS, Concurrent Versions System [5] overcomes this restriction. The main limitation of these tools is that being command line based there is very little workspace and little temporal awareness. Users only know when and by whom complete files were modified.

Furthermore since the version control system is distinct from the editing tools used so much information is lost, such as exactly what was added or deleted and when. Merges of multiple versions are possible but only by calculating the differences using algorithms similar to that used by the UNIX diff [6] command.

2.3. Collaborative writing with concurrent version control

While it may seem that a combination of the two technologies outlined above would provide a suitable system for distributed software development, their lack of integration severely limits their usefulness. While modern collaborative writing tools provide good workspace awareness within the document neither technologies could easily provide awareness of all users' actions.

Given that users will traverse both the version and chunk hierarchies there is a strong need to provide temporal awareness so that one can ``catch up'' on changes that have occurred. Information encapsulated within the editing system must be available to the entire system. To effectively maintain workspace and temporal awareness the version control and editing systems must be integrated.

3. Collaborative software editor: Design Criteria

Given that an integrated version control and editing system is required any proposed system should forfill the following criteria:

Support both close collaboration and independent work. Users must be able to switch between combined and independent work with minimum difficulty.
Support awareness of close collaborators' actions.
Users must be able to see exactly what others working with the same version are doing. Close collaboration is only effective with adequate workspace awareness.
Support non intrusive awareness of all collaborators' areas interest. The programmer should be able to see roughly what every member of the group is doing, but not to such an extent as to obscure awareness of their close collaborators' actions.
Facilitate version control and version switching in a simple and intuitive manner. It must be quick and easy to create, edit, switch and merge versions of the source code. The results of merges must be able to be reviewed easily.
Provide information on the origin and temporal distribution of changes. Information describing the author, version and time of changes must be maintained to facilitate temporal awareness. Users will shift their focus not only around their current version of the source code but also between versions. Facilities must be provided to allow the user to ``catch up'' with changes that have occurred while their attention was diverted.
Minimise the costs of collaboration. Collaboration must not impose additional burdens on the user. It should not be much more difficult to work in collaboration than alone.
Provide a good working environment for software development. The system will not be acceptable if it is not up to the standard of conventional single user software development environments.

4. Medusa

I have developed Medusa, a prototype multiple session WYSIWIS (what you see is what I see) distributed application to support collaborative software development. Medusa was written using Tcl/Tk [464] and the GroupKit toolkit [347].

The interface consists of two main windows, one showing the versions or source code and the other showing the ``chunks'' of code within the project. Their versions windows, Figure VersionWin , shows a directed graph of the versions that exists in the project. Small dots above the version provide conference wide workspace awareness by indicating the version that each participant is currently working in. A table on the left shows the users' colours and their present version.

From this window the user can select a version to work with or view. Versions with children become read-only so can be viewed but not edited. Each version has an associated colour facilitate text colour highlighting by version.

New versions can be spawned from existing versions. When a child of multiple parents is created chunks with versions in both parents are merged, the results of the merge can be easily checked because only merged chunks will have new versions, eg After merging versions 1.1a and 1.1b to form version 2.0, the only chunks shown as version 2.0 in the chunk view will be those that resulted from a merge of multiple parent version chunks. All other chunks will be of earlier versions as they will not have changed from the parent version. The various text colour options within the editor (see below) allow the text to be coloured by contributing version, Figure EditWin shows the results of the merge of versions 1.1a and 1.1b of chunk ``widgets''.

Picture: Versions Window. The user and one other participant are working in version 3.1b while another edits version 3.1a.

The source code for each file is divided into a hierarchy of discrete `chunks',a concept borrowed from literate programming [679,681]. This eases the recognition of areas of the system that have been modified as only the chunks titles must be viewed rather than the entire source code. The chunk hierarchy is displayed in the Chunks window, Figure TreeWin. The name and version of each chunk is displayed alongside its icon. Only information relating to users working in the current version is shown. Open chunks are shaded and dots to the right of the chunk names show which chunk each member of the current version has in focus.

Picture:Chunks Window. Both users working in version 3.1b have the chunk ``widgets'' in focus. The first two chunks are unchanged from their initial version 1.0

When a chunk is opened an Edit window is created, Figure EditWin. Participants operating in the same version are working toward a common goal so operate in a strict WYSIWIS fashion, all have an identical set of chunks open at any one time. Each Edit windows is equipped with multi-user scroll bar and Telepointers. Combined with the location indicators in the Chunks window these provide the much needed workspace awareness among programmers working on the same version.

An Editing Window. Text is coloured to show the contributing versions after the merge of version 1.1a and 1.1b to form version 2.0. Text from versions 1.0, 1.1a, 1.1b and 2.0 are shown.

The text within the edit windows can be coloured to indicate the origin of the text, either by version or user. This is possible as each version and user are assigned a colour. Temporal awareness is supported by only colouring changed since a specific time, this can be:

Since the user last edited the text.
Since the user hit the Mark button
Since the chunk was opened
Since the program was started or
Since the current version was created.

Optionally deleted text can be shown, it is coloured in a similar fashion but in a ``strike-out'' font.

These complex highlighting schemes are needed so that users can ``catch up'' with changes that have occurred since their attention was diverted to other chunks or versions within the system. This is especially useful after a version merge operation (see above).

4.1 Implementation details

To support the multiple tiers of collaboration framework, the concept of the session was introduced. A session is a collaborative grouping within a conference (users working in the same version in Medusa). The gk_toSession command was constructed, a session-wide equivalent of the GroupKit conference-wide gk_toAll command. This provided a simple and consistent method of separating sessions within the application. Similarly the sub-conference equivalent to the conference level gkBind updateEntrant binding, the updateNewSessionMember {user} procedure was created.

Multiple schemes for viewing text was made possible by maintaining multiple text editing objects, ten for each open chunk (normal and ``show deletions'' copies for each of the five time frames). Only one of these is mapped to the screen at any one time. Since some text objects show deletions the coordinates are not consistent across all views. All insertions and deletions have their locations mapped to a common addressing scheme which is mapped by each text object to its local coordinate system.

5. Further work

Medusa is a prototype system, to accurately evaluate its usefulness as a collaborative software development the interface would have to be brought up to the level of equivalent commercially available single user environments. Also the version management functionality could be extended. Improvements include:

Editing multiple chunks in one window with the option of expanding chunks in line.
Allow arbitrary version heritages, currently multiple parented versions can only be created if both parents share a common parent. A complete system would allow the merging of any arbitrary versions.
Multiple editing views of the same chunk(s).
Undelete of deleted text and undo of insertions.
Search and replace editing tools.
Hide chunks that are not present in the version being displayed.
Highlighting of chunks in the chunk view to similar criteria as the text highlighting in the edit windows, eg Show chunks changed since last edit.
Deletion of chunks and versions.
Complete equal opportunity between chunk and edit windows, ie allow adding and removing sub chunks from either window.

Extensive user trials are needed to evaluate the utility of the multiple levels of collaboration paradigm.

6. Conclusions

I have demonstrated the special needs of collaborative software development. Users must be able to work both in close collaboration and independently necessitating multiple tiers of collaboration. There is a critical need to maintain workspace and temporal awareness derived from the complexity of multi levels of collaboration and the need for users to traverse large volumes of data.

Current tools while providing parts of the solution are not effective in the application domain both because of the complex nature of the task domain and the need for integration to provide workspace and temporal awareness.

My prototype system, Medusa, while still under development provides sophisticated mechanisms for provide multiple tiers of collaboration while maintaining workspace and temporal awareness.